Michael Stapelberg recently posted a blog post about looking into the number of Debian Developers actively working on RC bugs for the upcoming wheezy release. In this blog post I analyze the data shared by Michael and provide the R commands used to generate the plots & findings. If you are interested into looking into the data yourself, but don t like R, I suggest using ipython notebook + numpy instead.

Analysis After parsing the data file we typically want to get an understanding of the data, by using summary(bugs) we get the minimum(1), median(5), mean(15.4), max(716) and quantiles of the data. This shows that the number of messages is wide-spread and a few people contribute a lot. To visualize the dispersion of the data we can create a box plot showing the range of messages: As the first and third quantile are close together we can assume that the majority of the work is done by a few, especially since the second quantile is 5. This is supported by the histogram below, where the x axis is the number of recorded messages and y is the number of developers.

Top 10 contributors The TOP 10 contributors, according to the dataset, are:

1. Lucas Nussbaum - 716 messages
2. Gregor Herrmann - 270 messages
2. Jakub Wilk - 270 messages
4. Andreas Beckmann - 225 messages
5. Julien Cristau - 205 messages
6. Cyril Brulebois - 169 messages
7. Moritz Muehlenhoff - 162 messages
8. Michael Biebl - 159 messages
9. Salvatore Bonaccorso - 158 messages
10. Christoph Egger - 142 messages

r commands These are the commands used to generate the plots and information in this plot:

bugs <- read.csv("by-msg.csv")
summary(bugs)
boxplot(bugs$rcbugmsg, log='y', range=0, ylab="# bugs")
quantile(bugs$rcbugmsg)
0%  25%  50%  75% 100%
1    2    5   12  716
# create histogram
llibrary('ggplot2')
ggplot(bugs, aes(x=rcbugmsg)) + geom_histogram(binwidth=.5, colour="black", fill="black") + scale_x_sqrt()
top10 <- tail(bugs[order(bugs$rcbugmsg),], 10)
top10

After a release cycle longer than between each beta (which is slightly sad, but I can t spend all my time on Debian), here comes the first release candidate of the Debian Installer for Wheezy. The Debian Installer 7.0 RC1 announce on the website has links to relevant bug reports in the Debian BTS, and the errata page lists things you probably want to know about (including gotchas with grub-install we ve been having for a while, now diagnosed, and hopefully fixed for the next release candidate). According to Arwen s sleepy attitude, it s officially time for a nap!

Playing the DPL Game: here are my nominations for the Fantastic Four:

• Cyril Brulebois
• Ansgar Burchardt
• Scott Kitterman
• Pino Toscano

P.S. Sorry Joss, I m not your man

* Inspired by DPL Game post. Not in order,
1. Christian Perrier
2. Martin Zobel-Helas
3. Russ Allbery
4. Cyril Brulebois Pick anyone. All four are capable leaders! Although, I only met Christian personally from list, I ve watched others doing great work in Debian since long time.

#696699 was already a funny bug number, but #696969 is even better. d-i FTW!

I ve been working on some autotesting features for d-i over the past few weeks, and I ve started lagging behind on my debian-boot@ reading accordingly, by several hundreds of mails. Today s gift to myself: no more unread/unanswered mails in that mailbox! Even if I ve prepared things for a possible d-i wheezy rc1 release around Christmas, several things weren t ready, most notably: grub-installer. Hopefully #696615 will be fixed soonish, probably by asking where to write when /target(/boot) isn t on (hd0). Wanted! Speaking of grub-installer, if anyone can reproduce #681227, I m all ears! Wouter has a workaround for it (only in sid for now), but I d very much like to track down the root cause for that one. It is supposedly reproducible with wheezy beta 4 images and with weekly builds (they use components from testing), all of those are available from the debian-installer website.

Problem #3: How to find out what s going on with debconf? Slightly longer version: As reported in #679327, the grub prompt during the installation process is entitled Configuring man-db , which isn t exactly great. Given man-db is a known dpkg trigger, I suspected this would be the reason for the broken title, and here s how I debugged it. For starters, using d-i basically means asking a lot of questions, which is implemented using the debconf mechanism. One should note that two implementations are available:

1. the historic implementation, in Perl: debconf
2. the C reimplementation: cdebconf

d-i uses cdebconf udebs, but joy begins when packages get installed in /target: debconf is used there. We ll see why that matters. Recipe #3: Set DEBCONF_DEBUG=developer and read logs!

1. Both implementations support the DEBCONF_DEBUG environment variable. The installer supports passing that as a kernel parameter; example from the syslinux prompt: select the Graphical install entry, press Tab , remove -- quiet and put DEBCONF_DEBUG=developer there instead.
2. Let s look at /var/log/syslog; there s a tail -f on it in VT4, but one can run grep and friends on it in VT2 or VT3. There, one can see what happens at the debconf level (the debconf protocol is documented in debconf-devel(7)). Tiny excerpt (timestamps removed for clarity):

   frontend: --> GET preseed/early_command
   frontend: <-- 0
    
   frontend: --> GET debian-installer/framebuffer
   frontend: <-- 0 true
    
   debconf: --> GET debconf/language
   debconf: <-- 0 en
   debconf: --> SET debconf/language en
   debconf: Setting debconf/language to en
   debconf: <-- 0 value set
   debconf: --> GET debconf/priority
   debconf: <-- 0 high
   debconf: --> GET rescue/enable
   debconf: <-- 0 false
   

3. The interesting point was titles, right? So let s look at the last TITLE occurrences:

   debconf: --> SETTITLE debian-installer/main-menu-title
   debconf: --> SETTITLE debian-installer/grub-installer/title
   in-target: debconf (developer): ----> TITLE Configuration de man-db
   debconf: --> TITLE Configuration de man-db
   in-target: debconf (developer): <-- TITLE Configuration de man-db
   in-target: debconf (developer): ----> TITLE Configuration de man-db
   in-target: debconf (developer): ----> TITLE Configuration de grub-pc
   debconf: --> TITLE Configuration de grub-pc
   in-target: debconf (developer): <-- TITLE Configuration de grub-pc
   in-target: debconf (developer): ----> TITLE Configuration de grub-pc
   in-target: debconf (developer): ----> TITLE Configuration de man-db
   debconf: --> TITLE Configuration de man-db
   in-target: debconf (developer): <-- TITLE Configuration de man-db
   in-target: debconf (developer): ----> TITLE Configuration de man-db
   in-target: debconf (developer): ----> TITLE Configuration de grub-pc
   debconf: --> TITLE Configuration de grub-pc
   in-target: debconf (developer): <-- TITLE Configuration de grub-pc
   in-target: debconf (developer): ----> TITLE Configuration de grub-pc
   debconf: --> SETTITLE debian-installer/grub-installer/title
   

   Bad news: the last one is about grub, so the title should be correct, right?
4. At this point, it might be the Gtk frontend behaving strangely. It s shipped in cdebconf-gtk-udeb, built from the cdebconf source. Let s look:
   • src/modules/frontend/gtk/ui.c has cdebconf_gtk_update_frontend_title(), which does what the function name suggests.
   • src/modules/frontend/gtk/di.c has cdebconf_gtk_di_run_dialog(), which calls the first function.
   • src/modules/frontend/gtk/progress.c has cdebconf_gtk_show_progress() (also calls the first function), which comes with the following comments:

     /** Show the progress widgets.
       *
       * This will actually add the widgets to the corresponding containers.
       * The main title saved when starting the PROGRESS operation will be restored
       * from the value saved when START was called.  This is needed when GO is
       * called during a PROGRESS operation.
     

   Now that s something! Even if the last entry is about grub, some previous value could be restored and could be the reason for the bad behaviour (that is easily confirmed by adding some debug_printf() calls on fe->title in cdebconf, thanks to an extra "debug.h" include). Maybe that s what needs fixing!
5. Now it s time to take a step back. A d-i environment is nice, but testing things can easily become a burden. Taking a random wheezy or sid chroot, and installing/removing a tiny package shipping a manpage should be enough to run into the man-db trigger. Exporting DEBCONF_DEBUG=developer there too, let s either install or remove x11-apps (the trigger does the same job, and the debconf trace is the same), here s the output:

   Processing triggers for man-db ...
   debconf (developer): frontend started
   debconf (developer): frontend running, package name is man-db
   debconf (developer): starting /var/lib/dpkg/info/man-db.config configure /usr/share/man
   debconf (developer): <-- VERSION 2.0
   debconf (developer): --> 0 2.0
   debconf (developer): <-- INPUT medium man-db/install-setuid
   debconf (developer): --> 30 question skipped
   debconf (developer): <-- GO
   debconf (developer): --> 0 ok
   debconf (developer): starting /var/lib/dpkg/info/man-db.postinst triggered /usr/share/man
   debconf (developer): <-- VERSION 2.0
   debconf (developer): --> 0 2.0
   debconf (developer): <-- GET man-db/auto-update
   debconf (developer): --> 0 true
   

   Even if one didn t know about the cdebconf/debconf thing, the frontend started bit in the d-i syslog would have been the key: it s only found in debconf, in the frontend script. That one has several ways to determine the package being acted on, and it finally calls:

   debug developer => "frontend running, package name is $package";
   $frontend->default_title($package) if length $package;
   

   Tada, that s likely to be the issue.
6. Tweaking that frontend script, it s easy to make sure that the code path for this use case is:

   elsif ($ARGV[0]=~m!^.*/(.*?)\.(?:postinst postrm prerm)$!)  
           $package=$1;
    
   

   Since $ARGV[1] is the action being passed to the maintainer script, one can intercept the triggered action, and avoid emitting a title update in this case; I ve therefore reassigned #679327 to the debconf package, and proposed a patch implementing that, which Joey Hess seems to find reasonable.

In my message to the bug report I wrote I actually tested it in a d-i environment, and made sure the issue had gone away. How I did that will likely be described in the next d-i hacking recipe.

Today s recipe:

• a day off
• a long night of sleep
• acid jazz music
• some 24 episodes
• coffee
• trout and pasta
• sleepy cats

Result: Debian Installer 7.0 Beta4 release! Speaking of which, shameless plug: I'm giving a Debian Installer talk at mini-DebConf Paris this sunday.

While I m not a big fan of clicky-clicky applications, I find it quite nice to be able to select some WEP/WPA settings in a GUI (as opposed to configuring wpa_supplicant manually) once in a while (new home, new couch by a friend s, new phone), and be done with it forever. Having mostly used Xfce over the years, I naturally came to trying out Wicd around 2006 (according to Wikipedia), and it looked like it did the job. It s been on all my laptops since then, and things were quite fine until the last laptop switch. For some (to be determined) reasons, that one comes up with a soft-blocked (rfkill) wireless LAN, which makes Wicd the biggest pain I have ever experienced as far as networking is concerned (see 4th bug report below). So I finally decided to try out that network-manager thing people apparently love to hate. A few bugs were filed in the process:

• #692413: wicd-daemon: /etc/init.d/wicd stop doesn t kill wpa_supplicant
• #692414: network-manager: /etc/init.d/network-manager stop leaves wpa_supplicant behind
• #692417: wicd-daemon: Continuously, ridiculously runs ifconfig/iwconfig
• #692418: wicd-daemon: Fails to automatically (re)connect after rfkill unblock

I think nm-applet is the only Gtk3 application I have, meaning slightly bad visuals (no integration with the current Gtk2 theme for other applications), but besides that, everything is now running smoothly. Bottom line: contrary to Wicd, NetworkManager just works! I can t tell for sure since I m not using Gnome, but I m not sure why somebody would want to use Wicd there as it s clearly inferior on a technical level. Maybe something about the GUI/CLI? At least NetworkManager knows about netlink sockets, doesn t waste resources through useless polling, and is able to figure out when connections need kicking. That one just does its job. What triggered this Wicd NetworkManager switch is a look at the linux source, which reminded me of some strange polling noticed while playing around with auditd, as mentioned in #692417; that and the no network at boot-up unless one triggers several actions in a Wicd client bit.

Problem #2: How to add a wireless module to a d-i image? Slightly longer version: As reported in #686605, a whole wireless module family is missing from the linux kernel udebs, meaning they re missing from the d-i images. Please note the hypothesis here is that the regular linux kernel images contain the relevant modules, only the udebs don t. Recipe #2: Craft a local udeb!

1. The following assumes one is interested in adding a wireless module, but that can be adapted to other module families. The relevant udeb base name is nic-wireless-modules.
2. When it comes to linux kernel modules, picking the right ones is important, so one has to consider the ABI. Right now, the current ABI in testing is 3.2.0-3-amd64. The complete udeb name is therefore nic-wireless-modules-3.2.0-3-amd64-di.
3. If you re running a kernel with the same ABI, all good, relevant modules should be available under /lib/modules/$(uname -r), which is what will be assumed below. Otherwise, one would have to download a proper linux-image-$ABI package, and extract it into a temporary directory to grab the wanted module(s).
4. Determine the relevant module and its dependencies. As an example, I ll pick a Realtek module: rtl8192cu.ko. If it s loaded, one can use the following to detect its dependencies:

   $ lsmod grep rtl8192cu
   rtl8192cu              78863  0
   rtlwifi                81350  1 rtl8192cu
   rtl8192c_common        52602  1 rtl8192cu
   mac80211              192768  4 iwlwifi,rtl8192c_common,rtlwifi,rtl8192cu
   cfg80211              137140  3 mac80211,iwlwifi,rtlwifi
   usbcore               128498  7 ehci_hcd,usbhid,uvcvideo,rtlwifi,rtl8192cu
   

   But it isn t even needed to load the module to get those dependencies:

   $ /sbin/modinfo /lib/modules/3.2.0-3-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192cu.ko grep ^depends
   depends:        rtlwifi,mac80211,rtl8192c-common,usbcore
   

   Compared to what the d-i image contains, only rtlwifi and rtl8192c-common are missing.
5. Fetch the udeb using http://packages.debian.org/ or browsing your favourite mirror if you know the paths by heart.
6. Extract the udeb into a temporary data/ directory, along with its meta data:

   dpkg -x nic-wireless-modules-3.2.0-3-amd64-di_3.2.23-1_amd64.udeb data
   dpkg --control nic-wireless-modules-3.2.0-3-amd64-di_3.2.23-1_amd64.udeb data/DEBIAN
   

7. Copy the 3 modules under the relevant subdirectory under data/.
8. Update the version in data/DEBIAN/control, for example by adding the +local1 suffix.
9. Build a new binary package, using fakeroot to avoid owner/group noise in the diff:

   fakeroot dpkg -b data nic-wireless-modules-3.2.0-3-amd64-di_3.2.23-1+local1_amd64.udeb
   

10. Use debdiff to check the results:

    $ debdiff nic-wireless-modules-3.2.0-3-amd64-di_3.2.23-1*_amd64.udeb
    Files in second .deb but not in first
    -------------------------------------
    -rw-r--r--  root/root   /lib/modules/3.2.0-3-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192c-common.ko
    -rw-r--r--  root/root   /lib/modules/3.2.0-3-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192cu.ko
    -rw-r--r--  root/root   /lib/modules/3.2.0-3-amd64/kernel/drivers/net/wireless/rtlwifi/rtlwifi.ko
    Control files: lines which differ (wdiff format)
    ------------------------------------------------
    Version: [-3.2.23-1-]  +3.2.23-1+local1+ 
    

11. Put the resulting udeb under localudebs/ in your d-i build tree, and rebuild your image as usual. Almost-tada!

Why almost ? Because a firmware is needed, so one can go back to the 7th step, extract the proper file (lib/firmware/rtlwifi/rtl8192cufw.bin) from the non-free firmware-realtek package, and add it under data/lib/firmware/realtek/. Rebuild the udeb, rebuild the d-i image. Then: tada!

Foreword: This is the first blog post of a mini-series, trying to document some recipes about Debian Installer hacking. VirtualBox will probably be mentioned on a regular fashion, but most of those recipes should be easily adaptable to qemu/kvm. Problem #1: How to share some d-i logs without using the network? Slightly longer version: Investigating some issues on a wired-less virtual machine (Network Adapter 1 Disable Network Adapter), it s hard to get log files out of the virtual machine. Recipe #1: Use serial ports! Serial Ports Port 1 Enable Serial Port, then pick Raw File as Port Mode, and specify a file on the host system to gather logs. There s nothing to do on d-i side, the serial console appears automatically as /dev/ttyS0. From a console, one can extract the needed bits:

cp /var/log/syslog /dev/ttyS0
dmesg > /dev/ttyS0

Stuff/team I m currently involved with:

• Debian System Administration: I m just in the porter-* groups, so that I can fulfill installation requests in various chroots on Debian porterboxes; this means real DSA members can concentrate on more important things while still keeping the turnaround quick for developers who want to debug stuff on exotic architectures. Reminder for that procedure: Chroot Install Request Guidelines.
• After having maintained the kfreebsd-* buildds for a while, I m still in the wanna-build team, meaning I can take care of give backs, one of the most common requests on debian-wb-team@. It s been a while since it s been split up from debian-release@, and instructions are still available in wanna-build.txt. Basically: anything buildd-related goes to $arch@buildd.debian.org or debian-wb-team@lists.debian.org, with the sole exception of binNMUs, which are handled by the release team.
• Speaking of which, I joined the release team a few months ago; plenty of (not-so-)funny things to do, like coordinating transitions to testing, and more recently, dealing with unblock requests during the freeze. While the Debian world is usually driven by the just do motto, there s one area where one has to learn to say no, sorry . Hopefully people won t hate us for that, and we ll find alternative ways (like backporting specific fixes, or postponing new features until wheezy-backports is open).
• Given nobody on debian-boot@ stepped up to prepare new debian-installer releases, I figured I would give a hand there until somebody more involved with d-i would manage that on the long run. That s a lot of heavy work, trying to get all involved packages into shape at a given moment, and getting people to fix their stuff when anything breaks. Hopefully that ll work out and once CD images are ready, we should be able to run some more tests on those before officially publishing d-i beta 1.
• And since the CD team is also understaffed, I joined Steve McIntyre a while ago during a point release to see how that was done, and how I could help. Things drove me to the other teams above, so I couldn t help much so far, but at least I managed to build a few test images on pettersson (the very nice machine on which images are built), using the debian-cd account. The intent was to make sure debian-installer could safely migrate from unstable to testing. That has happened lately, so images are being prepared.
• And of course I m still maintaining the whole X stack, with the help of a few other guys on specific areas.

I don t feel like getting hit by a bus, but I would hate burning out and going away from all this. People have called repeatedly for help in core packaging team. And that has been true for the X Strike Force for a while (hint: Julien only managed to pull me into this because I ported the Graphical Installer from DirectFB to X11). The same holds with non-packaging teams. I m pretty sure Steve would love to see new members in debian-cd. I m also pretty sure having more people involved in the d-i team would be very nice, especially if one could find out how to make the whole release process less insane than it is currently. I guess we could try out new ideas right after the release; it feels to me that right now is just not the time to fight the current release process.

As already written, even though it seems, I didn't spend my time running at Debconf12. Or eating cheese... Or (tentatively) hiking volcanoes... Or helping people to kill each other with socks... Or drinking beers... Not *only* all of these (some of them at the same time, though hiking a volcano while eating cheese and drinking beers is not particularly easy)....but also some Debian work. So, I uploaded a backport of samba to squeeze backports and our squeeze users should now have the same samba version than wheezy ones. I also stopped several cronjobs on i18n.debian.net and moved some material there as links have been (or should be) moved to the brand new i18n.debian.org (and its alias l10n.debian.org). I did a major cleanup in tasksel, committed several fixes, proposed others for review (mostly to Joey Hess). All this in preparation for a soon-to-come upload, probably after D-I beta1 which has been prepared by Cyril Brulebois while he was.....not attending Debconf12.. I also followed the integration of Sorina Sandu's work on netcfg for link detection and network ESSID choice in Debian Installer. Sorina is doing well in her GSOC work, because she's clearly someone with great capabilities who we will, I hope, be able to keep contributing to Debian. We can also thank the mentoring work of Gaudenz Steinlin to guide Sorina through D-I's arcanes. I also went through the current status of debconf translation completeness in testing for the 7 languages that target 100% (Czech, German, Spanish, French, Portuguese, Russian, Swedish). Here, the point is mostly taking care that fixes are either:

• already fixed in unstable (therefore checking that unblock requests have been sent by maintainers)
• sent as a bug report (so that I can harrass package maintainers to fix it)
• under work by a localization team (so that I can pester them to move on)

I can we have good chances to achieve this goal for at least 6 of these 7 languages (Czech might be more tricky as several translations are not yet made). Finally, I also did most of my regular Debian work (which usually takes 1-2 hours every day)...and bits of my paid work (sorry for those people who I shared the table at breakfast, but that was my only common time window with my team at work). So, well, quite productive weeks, once again.

I read an interesting question about mutt on IRC some days ago, which was: how do I find out which threads I have trolled^Wtaken part in. Obviously, there s ~P to filter the mails I have sent (which uses addresses declared through the alternates config directives to know who I am). But how do I find about the whole thread? Easily enough, one can wrap a given search through ~( ) so that the whole threads containing the matching mails are selected. In this case: ~(~P). Given the amount of outstanding requests on debian-release@, one can use the following to only see the threads with unread mails: ~(~N), which helps spotting the threads where attention is needed. Thinking of it, that probably should become the default when opening a given Maildir Gotta love people with interesting questions.

A while ago, I used to use the Fixed font, which I very much liked, since it featured a quite decent Unicode coverage, and was available in tiny sizes. Then time passed, I switched systems a few times and it kind of disappeared. Terminus is also nice, but quite bigger (for a given terminal geometry, 60 lines for Terminus, 72 for Fixed). Today, wondering why some fonts I dropped in ~/.fonts weren't picked up by fc-cache -rv ~/.fonts/, I found out a configuration file was preventing fontconfig from considering them: /etc/fonts/conf.d/70-no-bitmaps.conf Kill it with fire, and tada: Fixed is back!

since most of the gcc 4.7 bugs are fixed by now, I looked again at the general RC bugs too this week. here's the usual short report:

• #650060 snort: "snort: FTBFS with multiarch libmysqlclient-dev"
  apply patch from Ubuntu / Jean-Louis Dupond, upload to DELAYED/2, then used in a maintainer upload
• #664933 src:fceu: "fceu: FTBFS: file.c:157:20: error: request for member 'have' in something not a structure or union"
  add patch from Sebastian Ramacher, upload to DELAYED/2
• #666225 src:deja-dup: "configure:3028: error: xmllint not found"
  update build dependencies, upload to DELAYED/2
• #666337 src:euler: "euler: FTBFS: gcc: error: unrecognized option '-V'"
  sponsor NMU prepared by Sebastian Ramacher, upload to DELAYED/2
• #667111 bcov: "bcov: ftbfs with GCC-4.7"
  second attempt, extend patch, upload to DELAYED/1
• #667391 telepathy-qt4: "telepathy-qt4: ftbfs with GCC-4.7"
  add patch from Cyril Brulebois, upload to DELAYED/2
• #667886 src:textedit.app: "textedit.app: FTBFS with GCC-4.7"
  apply patch from Yavor Doganov, upload to DELAYED/2
• #672356 libspread-perl: "libspread-perl: DynaLoader now requires versions to be numbers, Spread.pm uses a string."
  add patch from Andrew Ruthven, do a QA upload
• #674330 src:clamav: "clamav: FTBFS: llvm/lib/ExecutionEngine/JIT/Intercept.cpp:69:67: error: 'lseek64' was not declared in this scope"
  apply upstream patch (missing include), upload to DELAYED/2

new week, new report about my work on RC bugs. again, mostly gcc 4.7 related, & again, mostly using patches prepared by others.

• #667111 bcov: "bcov: ftbfs with GCC-4.7"
  add patch from Cyril Brulebois, upload to DELAYED/2
• #667308 oggvideotools: "oggvideotools: ftbfs with GCC-4.7"
  add patch from Paul Tagliamonte, upload to DELAYED/2
• #667322 pianobooster: "pianobooster: ftbfs with GCC-4.7"
  add patch to fix Windows linker flags, upload to DELAYED/2
• #667329 powertop: "powertop: ftbfs with GCC-4.7"
  add patch from Cyril Brulebois, upload to DELAYED/2
• #667361 rtorrent: "rtorrent: ftbfs with GCC-4.7"
  add patch from Cyril Brulebois, upload to DELAYED/2, later fixed in maintainer upload
• #667362 rubberband: "rubberband: ftbfs with GCC-4.7"
  add patch from Cyril Brulebois, upload to DELAYED/2
• #667364 rutilt: "rutilt: ftbfs with GCC-4.7"
  add patch from Cyril Brulebois, upload to DELAYED/2
• #667388 tagcoll2: "tagcoll2: ftbfs with GCC-4.7"
  manual close
• #667403 uisp: "uisp: ftbfs with GCC-4.7"
  add compiler flag, upload to DELAYED/2
• #667419 xdiskusage: "xdiskusage: ftbfs with GCC-4.7"
  add patch from Cyril Brulebois, upload to DELAYED/2
• #667866 src:cenon.app: "cenon.app: FTBFS with GCC-4.7"
  add patch from Yavor Doganov, upload to DELAYED/2
• #667873 src:gridlock.app: "gridlock.app: FTBFS with GCC-4.7"
  apply patch from Yavor Doganov, upload to DELAYED/2
• #667874 src:gworkspace: "gworkspace: FTBFS with GCC-4.7"
  add patch from Yavor Doganov, upload to DELAYED/2
• #672003 src:dibbler: "dibbler: FTBFS: ClntIfaceIface.cpp:34:49: error: 'unlink' was not declared in this scope"
  add patch from Paul Tagliamonte, upload to DELAYED/2
• #672025 src:mmpong: "mmpong: FTBFS: client.cpp:276:71: error: 'usleep' was not declared in this scope"
  add patch from Cyril Roelandt, upload to DELAYED/2
• #672042 src:l2tp-ipsec-vpn-daemon: "l2tp-ipsec-vpn-daemon: FTBFS: src/VpnClientConnection.cpp:167:60: error: '::chown' has not been declared"
  add patch from Paul Tagliamonte, upload to DELAYED/2
• #672089 src:icewm: "icewm: FTBFS: Xlib.h:1694:1: error: 'deprecated' was not declared in this scope"
  add patch from Ubuntu / Andreas Moog, upload to DELAYED/2, then included in maintainer upload
• #673286 gem: "gem: FTBFS with gcc-4.7"
  send debdiff to the BTS, later NMUd by a fellow DD
• #674301 src:libplack-middleware-reverseproxy-perl: "libplack-middleware-reverseproxy-perl: FTBFS: tests failed"
  upload new upstream release (pkg-perl)
• #674304 src:clusterssh: "clusterssh: FTBFS: tests failed"
  add missing build dependency
• #674395 src:libdbd-mysql-perl: "libdbd-mysql-perl: FTBFS: ld: cannot find -lssl"
  manual close (pkg-perl)

While investigating the case of some packages responsible for uninstallability on the s390x architecture, I stumbled upon one FTBFS on a single architecture, reported as #673590 (<insert some nice words about software shipping with a decent testsuite>). Given the int versus size_t question was asked, I grabbed this old (it s UNIX!) reference: 64-bit and Data Size Neutrality. Among other things, it describes the everything is 32-bit to 64-bit is becoming the new standard slow conversion process, where keeping compatibility with existing applications was a high priority. It has a nice description of so-called C data models, making it possible to refer to them quickly: LP32 and ILP32 in the 32-bit world; ILP64, LLP64, and LP64 in the 64-bit world. I won t go into detail here, this page has a nice table and lots of explanations about pros and cons for those. (On a personal note, I discovered those on xorg-devel@ when I saw patches floating around, which were about optimizing data sizes for this or that data model, by picking the right types.) While standards may be boring, this page makes it really easy to understand which data types to use, to ensure the best 32/64-bit compatibility possible. It s even full of dos and don ts. See the second half (Porting Issues) for details.

With the sound of the freeze approaching, we have been receiving a few more transition requests lately. Thankfully, a lot of them can apparently be processed at the same time, that's why we have currently the following, crazy tracker summary: Of course there are some transitions that started because maintainers forgot how transitions are supposed to work, but we re trying to get things done anyway.

like in the last two weeks, this week's bug squashing was mostly related to the gcc 4.7 FTBFS bugs:

• #667139 coin3: "coin3: ftbfs with GCC-4.7"
  send debdiff to the BTS
• #667238 lfhex: "lfhex: ftbfs with GCC-4.7"
  add patch to add missing include, upload to DELAYED/5
• #667263 linamc: "linamc: ftbfs with GCC-4.7"
  patch to enable missing include, upload to DELAYED/5
• #667272 mcmcpack: "mcmcpack: ftbfs with GCC-4.7"
  add patch to add this-> qualifiers, upload to DELAYED/5
• #667277 milkytracker: "milkytracker: ftbfs with GCC-4.7"
  add patch to add missing include, upload to DELAYED/5
• #667281 minitube: "minitube: ftbfs with GCC-4.7"
  add patch to add missing include, upload to DELAYED/5
• #667284 mm3d: "mm3d: ftbfs with GCC-4.7"
  patch to add include and this-> qualifiers, upload to DELAYED/5
• #667289 mswatch: "mswatch: ftbfs with GCC-4.7"
  add patch to add missing include, upload to DELAYED/2
• #667292 musique: "musique: ftbfs with GCC-4.7"
  add patch to add missing include, upload to DELAYED/2
• #667295 netperfmeter: "netperfmeter: ftbfs with GCC-4.7"
  add patch to add missing include, upload to DELAYED/2
• #667298 nmapsi4: "nmapsi4: ftbfs with GCC-4.7"
  add patch from Francesco Cecconi (add missing includes), upload to DELAYED/2, then solved with a maintainer upload
• #667302 numptyphysics: "numptyphysics: ftbfs with GCC-4.7"
  add patch to add missing include, upload to DELAYED/2
• #667303 nxcl: "nxcl: ftbfs with GCC-4.7"
  add patch to add missing include, upload to DELAYED/2
• #667318 owx: "owx: ftbfs with GCC-4.7"
  add patch to add missing include, upload to DELAYED/2
• #667337 qbankmanager: "qbankmanager: ftbfs with GCC-4.7"
  add patch to use class name, upload to DELAYED/2
• #667343 qterm: "qterm: ftbfs with GCC-4.7"
  add patch from Paul Tagliamonte (missing include), upload to DELAYED/2
• #667347 rafkill: "rafkill: ftbfs with GCC-4.7"
  add patch to add missing include, upload to DELAYED/2
• #667348 ragel: "ragel: ftbfs with GCC-4.7"
  patch to this-> qualifiers, upload to DELAYED/2
• #667373 simgear: "simgear: ftbfs with GCC-4.7"
  apply patch from Matthias Klose, upload to DELAYED/2
• #667428 zoneminder: "zoneminder: ftbfs with GCC-4.7"
  add patch from Cyril Brulebois, upload to DELAYED/2
• #669432 src:milkytracker: "milkytracker: FTBFS: ./zzip_file.h:34:18: fatal error: zlib.h: No such file or directory"
  add missing build dependency, upload to DELAYED/5